企业云主机数量增加后，为什么需要改变传统管理方式？

只有一台云主机的时候，运维是件轻松的事。需要什么操作，用远程桌面或者SSH登上去，几条命令就解决了，哪台机器跑着什么，一目了然。

机器多起来之后，情形就不一样了。日常的工作会变成这样：不同的服务器要分别登录，资源状态得逐台检查，同样的配置调整要在每台机器上重复执行一遍，业务临时需要开一台测试机、用完又要关掉，开关实例的事一天能来好几回。如果团队里不止一个人在管，谁能操作哪台机器、改了什么，还得互相协调。

靠人工登录、逐台操作的方式，问题不在于做不到，而在于容易带来几个后果。效率低，同一件事要重复做很多遍；操作不一致，甲在这台机器上改了某项配置，乙在另一台上忘了改；记录不完整，过一段时间，没人说得清某台机器上曾经被动过什么。

解决的思路，是把管理方式往上抬一层。先从手动管理走向平台化管理，把分散的操作集中到统一的入口；再根据企业的需要，逐步走向自动化运维，把重复的操作交给程序去执行。下面先从控制台说起。

云主机控制台是什么？它能帮助企业完成哪些管理工作？

实例查看与基本状态管理

控制台最基础的作用，是让所有云主机一目了然。实例列表里可以看到名下有多少台云主机，各自的运行状态如何，以及配置、IP等资源信息。从“登录每台机器看一看”，变成“打开一个页面看全部”，对机器数量较多的企业来说，省下的时间是实打实的。

常用操作集中完成

开通、关闭、重启、升级，这些基础的管理操作，都可以在控制台里完成。这类操作频率高、步骤固定，集中到统一入口之后，不同的人用同样的方式去做，因习惯不同带来的差异就少了。涉及到平台层面的事情，比如升级配置，控制台也是最直接的操作路径。

远程终端及操作入口

这里有两类入口，用途不同，值得分开说。Web管理入口管的是云主机这个“资源”：开机、关机、升级，属于平台层面的事。远程终端，以及SSH、远程桌面这类远程连接工具，是用来进入系统内部的：安装软件、修改配置文件、查看日志。前者像是管理机器的开关和规格，后者像是坐到机器面前去操作。企业日常两种都要用，只是要清楚各自管的是哪一层。

资源使用情况查看

控制台还可以集中查看CPU、内存以及磁盘I/O等信息。把多台云主机的资源使用情况放在一起看，哪台负载偏高、哪台长期空闲，一眼就能看出来，也为后续调整配置提供了依据。这一节只谈控制台作为统一入口的作用，监控和安全方面的技术，这里不展开。

什么是云主机API？为什么企业开发团队需要关注它？

API如何连接企业应用与云资源管理平台？

API可以理解为程序和程序之间对话的约定。控制台是给人用的，有页面有按钮；API是给程序用的，程序按照规定的格式发出请求，云平台处理之后，把结果返回给程序。

举两个简单的场景。企业内部有一套运维平台，希望在一个页面上显示所有云主机的状态，它就可以通过API读取云主机的信息，不必让运维人员到控制台里一条条去抄。再比如，公司的项目上线有一套流程，其中一步是给新项目准备服务器，流程系统可以在这一步直接调用云资源管理的接口，把实例开出来。

API与人工操作相比，有什么区别？

区别主要在三个方面。重复的操作可以标准化，同一个操作由同一段程序去执行，每次的步骤和参数都一样，不会因人而异。操作流程可以自动化，几个步骤能串成一个流程，自己跑下去，不用有人守着一步步点。系统之间还可以交换数据，云主机的信息能流入企业的其他系统，其他系统发出的指令，也能传给云平台。

不过也要看到另一面。人工操作时，人会随时判断“这样做对不对”，程序则会严格按指令执行，指令有误，就会批量地出错。所以API带来的是效率，同时也对规范和谨慎提出了更高的要求，后面会讲到。

API适合哪些企业管理场景？

常见的场景有这几类：批量管理实例，比如一次对几十台机器执行同一个操作；自动化的项目部署，把开通实例、初始化环境串成流程；资源状态查询，定时获取各台云主机的运行情况；业务系统与云平台集成，让业务系统能直接调用云资源；还有内部运维平台的建设，在自己的平台里统一管理云资源。

需要强调的是，API具体能执行哪些操作，取决于服务商开放了哪些接口。有的服务商开放得比较全面，从开通到升级都能调用；有的可能只开放查询类的接口。所以评估的时候，要看服务商的API文档，不能默认“控制台能做的，API也都能做”。

企业如何利用API构建自动化云资源管理流程？

先看一个完整流程的例子，从业务提出需求，到操作完成：

业务申请资源  →  系统审批  →  调用云主机接口  →
创建或调整实例  →  获取实例信息  →  记录操作结果

业务部门在系统里提交资源申请，写明需要什么规格、用来做什么；系统按规则交给负责人审批；审批通过之后，程序调用云主机的接口，创建新的实例，或者调整已有的实例；操作完成后，程序获取实例的信息，比如IP和状态；最后把整个过程记录下来，包括谁申请的、谁批准的、做了什么、结果如何。整条链路里，真正需要人来判断的只有审批这一步，其余都可以交给程序。

这只是一个通用的流程示意。下面看三种典型的用法。

项目上线自动创建云主机

过去项目要上线，运维得先等需求单，再手动开机器、装环境。把这一步纳入标准化流程之后，资源申请、实例开通和后续配置就连成了一条线：申请通过就开通，开通之后执行初始化的配置。这样每个项目拿到的环境是一致的，也不会因为运维忙不过来而卡住上线。

批量执行日常管理操作

比如业务活动之前，需要同时重启或者升级一批机器，逐台登录去做，既慢又容易漏。通过接口批量执行，一次发出指令，既减少了重复操作，也留下了统一的执行记录。批量操作的风险相对更大，建议先在小范围试一遍，再放开范围。

将云资源接入企业内部管理平台

许多企业已经有资产管理、工单或者运维平台。通过接口，把云主机的资源信息同步进去，云主机就和其他IT资产一样，出现在企业现有的管理体系里，查询、统计、核对都在同一个地方完成，不用再另外维护一份表格。

以上都是通用的应用方式，并不表示它们都是恒讯科技现成提供的自动化功能。具体能做到哪一步，取决于开放的接口能力，后面的章节会再说明。

使用API管理云主机，需要注意哪些安全和技术问题？

API能做的事越多，用不好带来的风险也越大。下面分三类来说。

凭据方面。API密钥相当于一把能操作云资源的钥匙，要妥善保管，不要随手发给别人，也不要贴在聊天记录里。授权时遵循最小权限原则，只给程序完成工作所必需的权限，比如只需要查询状态的程序，用只读的权限就够了，没必要把能删除实例的权限也交出去。程序里不要明文存储敏感的认证信息，更不能把密钥直接写进代码再提交到代码仓库，可以放在环境变量或者专门的密钥管理方式里。

操作过程方面。重要的操作要保留记录：谁、什么时候、调用了什么、结果怎样，出了问题才有据可查。批量操作要设置必要的确认和异常处理，比如执行前先列出将被影响的实例，让人确认一遍，中途遇到错误能停下来，而不是一路执行到底。另外要处理好重复请求和接口超时。程序发出创建实例的请求后，如果超时没有收到回应，直接重试，有可能创建出两台实例。比较稳妥的做法，是重试之前先查询一下，上一次的请求是否已经生效。

接口本身的变化。要确认API的调用频率限制，短时间内发出太多请求，可能会被拒绝。也要关注接口的版本变更和兼容性，服务商升级接口之后，原来的程序还能不能正常工作，变更会通过什么方式通知，都要提前了解。

企业应该如何选择支持控制台和API的云主机服务商？

可以从五个方面来看。

首先是控制台，看它有没有提供可以正常使用的Web管理界面，常用操作是否齐全，用起来是否顺手，这是日常管理的基础。

其次是API。看服务商是否开放了API，有没有相关的技术文档，没有文档的接口，开发团队很难放心使用。再进一步，要看API覆盖哪些资源管理操作，是只能查询，还是也能创建、调整、删除，和控制台上的功能能对上多少。

第三是权限和认证机制是否清晰：密钥怎么申请、怎么更换，权限能不能分级，是否支持最小权限的做法。

最后，评估它能否满足企业后续的自动化管理需求。现在也许只用控制台，但如果一年后想建设内部运维平台，到时候服务商的API能力够不够用，最好在选择的时候就了解清楚。

恒讯科技云主机控制台与API管理能力

根据官网的云主机产品页面，恒讯科技云主机提供Web控制台、API管理方式和远程终端，支持开通、关闭、重启和升级云服务器，也支持查看CPU、内存和硬盘I/O的实时监控及报表。

把这些功能和前面的管理场景对应起来，大致是这样：企业可以通过控制台完成基础的资源管理，包括实例的开通、关闭、重启和升级，需要进入系统内部操作时，使用远程终端；CPU、内存和硬盘I/O的监控与报表，有助于掌握各个实例的资源使用情况。开发和运维团队则可以进一步根据开放的API能力，把云资源的操作整合到企业自己的内部系统里。

需要说明的是，前面讲的自动化流程是通用的方案，恒讯科技具体开放了哪些接口，支持怎样的认证方式，调用有什么限制，要以恒讯科技提供的API文档为准。有自动化需求的技术团队，建议在采购之前先向恒讯科技索取API文档，核对接口范围，再决定哪些环节适合自动化。

企业开始使用云主机自动化管理，应该从哪些操作入手？

不必一上来就做自动化。顺着“手动、平台化、自动化”的方向，可以分三步走。

先整理。统一服务器的命名和分类，比如按业务、按环境来命名，一看名字就知道它是干什么的；再建立实例和业务系统之间的对应关系，哪台机器属于哪个系统，由谁负责。这一步看起来琐碎，却是后面所有管理工作的基础。

再规范。统一管理人员的操作权限，谁可以开关机，谁可以升级配置，要有明确的划分。对常用的管理操作建立标准流程，写下来，让不同的人做出来的结果是一样的。

后自动化。确认了API能力之后，再逐步开展自动化，先挑频率高、风险低的操作，比如状态查询，再慢慢扩大到更复杂的操作。同时要同步形成操作日志和异常处理机制，自动化跑起来之后，出了问题能查、能停、能恢复。

控制台和API的价值，不只是多提供了几种操作方式。真正的意义在于，帮企业建立起一套标准化、可追踪、可扩展的云资源管理流程：操作有统一的入口，过程有记录，规模变大之后还能继续往上叠加。如果企业的技术团队有具体的管理需求，比如多台云主机的统一管理，或者对接内部的运维平台，可以向恒讯科技咨询云主机的控制台和API能力。